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1  Introduction 

This  document  is  the  final  report  of  ORCA’s  LNAVSIM  Phase  II  SBIR  effort  for 
AFRLA^ACD.  During  the  LNAVSIM  program,  ORCA  has  researehed  methods  and 
designed  software  tools  for  modeling,  planning,  and  simulating  missions  involving  large 
numbers  of  air  vehicles.  Through  the  LNAVSIM  R&D  effort,  ORCA  has  gained  valuable 
knowledge  about  the  needs  for  mission  modeling  and  simulation  tools,  and  the  challenges 
of  implementing  software  tools  to  support  operations  and  studies  involving  large  groups 
of  vehicles.  This  report  will  review  our  Phase  II  effort,  summarize  the  results  of  our 
research,  and  describe  the  LNAVSIM  tools  and  software  designed  over  the  last  two 
years.  All  documents,  reports,  and  briefings  prepared  during  Phase  II  ean  be  aceessed 
through  ORCA’s  LNAVSIM  website  www.ORConeeptsApplied.com/lnav. 

In  the  remainder  of  this  section,  we  will  identify  the  problem  this  research  effort 
addresses,  briefly  describe  our  vision  of  the  solution,  and  define  “large  numbers”  for  the 
purposes  of  this  program.  Seetion  2  discusses  mission  planning  teehnologies  identified  as 
necessary  for  groups  of  vehicles.  Section  3  gives  the  LNAVSIM  Coneepts  of  Operations. 
In  section  4,  we  deseribe  the  final  software  produet  of  Phase  II,  LNAVSIM  Version  1.0. 
Section  5  summarizes  the  three  LNAVSIM  studies  performed  during  Phase  11.  Finally, 
Section  6  provides  a  glimpse  at  the  possibilities  for  future  versions  of  LNAVSIM. 

1.1  Problem  Identification 

The  use  of  large  numbers  of  air  vehicles  (LNAV)  such  as  uninhabited  air  vehieles  (uavs) 
for  theater  reeonnaissance,  surveillanee,  target  deteetion  and  loeation,  defense,  eleetronie 
warfare,  and  unmanned  combat  air  vehicle  (ucavs)  for  taetieal  operations,  will  eontinue  to 
alter  the  theater  dynamie.  The  evolution  in  strategies  and  tactics  is  well  underway,  as  ean 
be  seen  in  reeent  operations  in  Afghanistan,  in  other  engagements  in  the  war  on  terrorism, 
and  in  Iraq.  However,  reeent  uses  of  unmanned  vehicles  have  been  limited  mainly  to 
single  vehicle  missions. 

The  Air  Force  is  investigating  ways  to  utilize  groups  of  eoordinated  air  vehieles  sueh  as 
uavs,  and  ucavs  as  a  means  to  locate  high-value,  strategic,  movable  targets,  enhanee 
situation  awareness,  and  deliver  frontal  wave  firepower  more  precisely,  and  with  less 
collateral  damage  and  injury  to  civilian  populations  than  traditional  means.  This 
underscores  the  need  for  eontinuing  investments  in  mission  planning  analytieal  tools, 
modeling,  and  mission  rehearsal  simulation  eapabilities  that  can  address  operational 
scenarios  involving  groups  of  highly  synehronized  uav/ucav  vehicles.  For  a  growing 
number  of  ehallenging  missions  that  involve  large  numbers  of  vehieles,  the  USAF 
envisions  an  advaneed  mission  planning  and  simulation  environment  that  is  rapid, 
flexible,  and  possesses  a  full  suite  of  mission  scenario  development  tools  to  study 
coordinated  and  eollaborative  force  structures.  Through  simulation,  the  critieal 
assessment  of  command,  control,  and  optimization  of  force  eomponents  for  planned  and 
postulated  battlefield  conditions  can  be  realized.  Furthermore,  through  simulation, 
mission  planning  specialists  can  evaluate  the  effectiveness  that  groups  of  vehieles  offer  as 
part  of  a  mueh  larger  task  force  structure. 
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Many  current  mission  level  models  and  simulation  tools  are  not  adequate  to  conduct 
effectiveness  studies  for  the  class  of  LNAV  problems.  Most  mission  planning,  modeling, 
and  simulation  systems  presume  small  numbers  of  aircraft  for  each  mission.  For  a  given 
class  of  aircraft  with  unique  characteristics  in  vehicle  performance,  susceptibility,  and 
weapon  delivery,  each  vehicle’s  optimized  route  is  largely  determined  by  the  mission 
objectives,  threat  exposure,  target  locations,  and  risk  element.  For  multiple  missions,  the 
“single”  vehicle  mission  context  is  extended  to  other  vehicles  over  the  number  of 
vehicles  utilized  in  the  airspace  simultaneously.  Although  this  may  appear  as  a 
coordinated  and  synchronized  effort,  each  route  being  simulated  is  essentially 
deterministically  derived  and  calculated  according  to  the  prescribed  mission  input  data 
governing  that  mission  and  the  vehicle  route  optimization  routines  being  utilized.  Each 
vehicle  route  generated  is  independently  determined  without  knowledge  from  the  other 
aircraft  executing  their  missions.  Today’s  approaches  in  aircraft  mission  planning  and 
simulation  are  characterized  as  simultaneous,  but  asynchronous  and  uncoordinated  with 
respect  to  vehicle  collaboration  (except  through  the  initial  assignment  of  targets  and 
objectives.)  The  sub-optimality  of  such  a  solution  will  tend  to  grow  with  force  size.  The 
approach  is  not  ideally  suited  for  controlling  multiple  air  vehicles  that  are  attempting  to 
cooperate.  The  work  we  are  undertaking  in  this  project  seeks  both  to  model  this 
cooperation  and  to  offer  new  methods  and  concepts  of  operations  for  collaborative 
plarming.  We  also  introduce  a  method  for  measuring  plan  robustness. 

This  research  effort  addresses  generic  air  vehicles  with  a  focus  on  unmarmed  vehicles. 
Although  there  may  be  references  to  actual  systems  (e.g..  Predator,  Global  Hawk,  or  the 
DARPA  UCAV  under  development),  our  goal  is  to  be  able  to  examine  all  types  of  air 
vehicles,  real  and  imagined.  The  concern  is  not  just  with  the  capabilities  of  individual  air 
vehicles  but  also  the  mission  plarming  and  command  and  control  elements  needed  to 
make  large  numbers  of  air  vehicles  work  together. 

1.2  The  LNAVSIM  Vision 

During  this  program,  ORCA  has  done  extensive  research  into  LNAV  mission  needs, 
requirements,  and  concepts  of  operation.  We  have  identified  necessary  LNAV 
technologies  and  algorithms,  developed  tools  based  on  these  technologies  and  algorithms, 
and  designed  an  architecture  for  the  LNAVSIM  environment. 

ORCA’s  vision  for  LNAVSIM  is  an  air  war  planning  and  simulation  environment  that  is 
indistinguishable  from  a  real-life  situation.  We  see  an  environment  in  which  multiple 
operators  each  control  a  group  (“pod”)  of  vehicles.  A  commander,  (e.g.,  the  Joint  Forces 
Air  Component  Commander  -  JFACC),  sets  values  for  mission  objectives,  and  assigns 
vehicles  and  objectives  to  the  individual  pod  operators.  Operators  develop  detailed 
assignments  of  objectives  and  route  plans  for  the  vehicles  under  their  control  with  the  aid 
of  automated  mission  planning  tools  available  though  the  LNAV  Generator  (LNAV GEN) 
server.  As  new  events  are  reported,  the  JFACC  makes  new  assignments  of  objectives. 
Operators  respond  to  new  objectives  and  pop-up  threats  by  analyzing  existing  plans  for 
significant  changes  in  figures  or  merit  (FOMs)  and  replanning  if  necessary.  The  Broad 
Overseer  of  the  Scenario  and  Simulation  (BOSS)  can  manipulate  the  initial  scenario  and 
simulation  events  by  adding,  deleting,  or  moving  entities.  Scripted  events  can  be 
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provided  to  the  JFACC  and  pod  operators  through  the  BOSS.  We  see  the  possibility  of  a 
Red  Commander  who  could  be  in  charge  of  the  threat  laydown. 


This  environment  represents  a  leap-forward  for  modeling  and  simulation  of  military 
missions.  The  high-level  vision  of  the  LNAVSIM  air  war  planning  and  simulation 
environment  is  captured  in  the  picture  below. 


The  LNAVSIM  Environment 
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Figure  1  The  LNAVSIM  Vision 

1 .3  “Large  Numbers”  of  Air  Vehicles 

One  of  the  first  steps  in  Phase  I  of  this  SBIR  program  was  to  research  AFRL  needs  for 
LNAVSIM.  In  ORCA’s  Phase  I  SBIR  proposal,  we  expressed  the  willingness  to  explore 
swarms  of  hundreds  of  micro  air  vehicles.  To  address  the  planning  requirements  for 
swarms  of  that  size,  ORCA  proposed  using  methods  for  generating  routes  for  large 
groups  of  vehicles,  often  referred  to  as  flocks  or  swarms,  using  the  “boids”  methodology 
developed  by  Craig  Reynolds'  for  computer  animated  bird  flocking.  However,  the  group 
consensus  at  AFRL  was  that  it  is  more  appropriate  to  focus  on  combinations  of  lethal  and 
non-lethal  uninhabited  air  vehicles  numbering  between  4  and  32. 

To  support  this  change  of  focus,  ORCA  investigated  a  variety  of  route  planning  methods, 
including  autorouting  individual  vehicles,  deconfliction  methods  for  groups  of  vehicles, 
and  the  boids  approach.  Phase  II  research  revealed  that  the  boids  methods,  while  allowing 
for  fast  generation  of  routes  for  groups  of  vehicles,  do  not  work  as  well  as  autorouting 
when  threats  are  present.  However,  in  cases  where  hundreds  of  vehicles  are  being 
employed,  the  group  will  be  easily  detectable  and  ensuring  the  survivability  of  individual 
vehicles  may  not  be  less  important  than  accomplishing  mission  goals.  For  small  groups, 
autorouting  combined  with  deconfliction  methods  is  fast  and  produces  more  survivable 
routes. 


'  Craig  Reynolds’  website:  http://www.red3d.com/cwr/boids/ 
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The  LNAVGEN  component  provides  OPUS  autorouting  services  through  the  OPUS  API. 
To  support  planning  for  larger  groups  and  to  provide  an  alternative  to  autorouting,  ORCA 
developed  a  modified  boids  approach,  called  swarm  management,  for  LNAVGEN. 
Swarm  management  address  some  current  planning  needs  and  supports  planning  for  large 
groups  should  the  concept  of  operations  for  LNAVSIM  evolve  in  the  future. 

2  LNAVSIM  Mission  Pianning  Technologies 

2.1  Target  Allocation 

For  uavs  and  ucavs,  cooperative  planning  can  be  essential.  Some  methods  of  target 
location  use  sensors  on  multiple  aircraft.  This  means  that  group,  or  pod,  planning  is  a  new 
element  of  mission  planning  that  must  be  addressed. 

When  tasks  are  assigned  to  pods  of  unmanned  vehicles,  it  is  almost  certain  that  the 
JFACC  will  not  have  sufficient  insight  into  pod  planning  and  capabilities  to  make 
assignments  by  tail  number.  Tasks  will  be  assigned  to  one  or  more  pods.  How  the  pods 
assign  tasks  to  individual  vehicles  is  a  target  allocation  problem.  This  problem  may  have 
to  be  solved  under  a  variety  of  circumstances — ^pre-mission  and  inflight  with  the 
possibility  of  new  targets  and  threats. 

Target  allocation  is  the  assignment  of  tasks  to  resources.  The  target  allocation  problem  is 
mathematically  equivalent  to  the  problem  known  in  computer  science  circles  as  the 
Vehicle  Routing  Problem  (VRP).  Once  the  target  set  has  been  designated,  assignments 
can  be  made  using  algorithms  developed  to  solve  the  VRP.  One  VRP  variation  models  a 
fleet  of  trucks  with  varying  capacity,  fuel  constraints,  and  capability  to  traverse  a  road 
network.  ORCA  worked  on  such  a  problem  in  a  military  context  as  well  as  for  an  Internet 
grocery  delivery  firm  driven  by  tight  time  windows.  Deliveries  and  pickups  are  subject  to 
time  and  dependency  constraints.  The  applicability  to  aircraft  delivering  weapons  and 
imaging  locations  is  obvious. 

2.1.1  VRP  and  HEX 

ORCA’s  internally  funded  research  on  the  VRP  began  in  1989.  An  initial  success  was  the 
development  of  an  algorithm  for  allocating  homogeneous  assets.  ORCA  improved  its 
target  allocation  methods  during  a  recently  completed  DARPA  JFACC  effort  and  in- 
house  R&D  that  continued  after  the  JFACC  program.  The  independent  R&D  program 
was  entitled  the  Heuristic  Evaluation  experiment  (HEX)  and  the  result  of  this  effort  was 
the  HEX  Target  Allocation  Algorithm. 

One  of  the  first  steps  in  the  target  allocation  process  is  to  generate  and  evaluate  several 
possible  route  plans.  The  route  plans  for  target  allocation  need  only  be  rough  estimates, 
rather  than  the  precise  routes  generated  by  an  autorouter  such  as  OPUS.  (After  the  target 
allocation  is  determined,  an  autorouter  can  be  used  to  generate  the  final  detailed  route 
plans.)  However,  a  large  number  of  routes — ^possibly  in  the  millions  depending  on 
problem  complexity — must  be  generated  quickly.  The  HEX  tool  generates  simplified 
routes  by  using  a  hexagonal  grid  to  model  vehicle  flight  paths  and  simplifying  other 
problem  parameters  such  as  threat  costs. 
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The  HEX  tool  uses  a  least  eost  path  algorithm  to  eompute  paths  between  any  two  nodes 
in  the  hex  grid.  Dynamic  costing  is  then  used  to  compute  least  cost  path  for  an  ordered  set 
of  objectives.  In  dynamic  costing,  paths  are  determined  based  on  the  order  in  which  tasks 
must  be  executed.  Finally,  the  Greedy  Random  Adaptive  Search  Procedure  (GRASP),  a 
technique  for  solving  the  VRP,  is  used  to  allocate.  GRASP  is  particularly  suitable  for 
target  allocation  as  any  initial  condition  can  be  used  as  a  starting  point.  This  allows  new 
tasks  to  be  added  to  existing  assignments  with  minimal  or  no  disturbance  to  other  vehicle 
plans.  During  the  allocation  process,  threat  and  vehicle  models  have  been  adopted  to 
provide  a  "good  enough"  answer,  leaving  the  details  to  the  route  planner. 


The  output  of  the  target  allocation  process  is  an  ordered  list  of  tasks  for  a  set  of  aircraft, 
similar  to  the  ATO.  The  task  list  is  input  for  the  autorouter. 

2.1.2  Synergetic  Effects  Model  (SEM) 

The  Synergetic  Effects  Model  (SEM)  is  used  to  model  the  effects  of  satisfying  single 
objectives  and  groups  of  objectives.  The  SEM  is  a  generalization  of  the  Prioritized  Target 
List  (PTL).  The  current  PTL  indicates  priorities  and  values  for  individual  objectives, 
which  could  be  targets  or  other  tasks  such  as  imaging  a  target.  The  SEM  models  the 
effects  of  satisfying  single  objectives  as  well  as  combinations  of  objectives.  It  expands  on 
the  concept  of  target  importance  by  also  attempting  to  capture  the  relationship  between 
objectives.  Because  the  SEM  models  the  relationship  between  objectives,  it  aids  in 
producing  coordinated  and  cooperative  mission  plans. 


^  The  Synergetic  Effects  Matrix  (SEM) 

tf'nieSEM^  «  two  dimcnsionil  generalization  of  the  Prioritized  Taiget  List  (PTL) 

•  A  current  day  PTL  indicates  individual  target/objective  priorities  and  values 

•  The  SEM  represents  the  value  of  achieving  single  objectives  as  well  as  combinations  of  objectives 


The  diagonal  entries  of  the  SiiM  arc  the 
values  of  the  objectives. 


I  he  nfr-diaj;<>na!  (i, ))  clement 
T  represents  the  synergetic  value  ot 


Kaample;  Suppose  there  arc  two  missiles  in  the  area  of  a  target 
tracker  radar.  The  diagram  shows  the  TTR  and  the  two  launch 
vehielcs  (SI  and  S2).  We  get  I  point  for  imaging  the  TTR 
(to  establish  its  exact  location)  or  for  taking  out  cither  missile. 
10  points  arc  earned  for  taking  out  the  TTK,  however,  an 
additional  100  points  arc  earned  if  wc  image  it  before  release 
of  our  weapon. 


Populating  the  SEM 

■  Suhjcci  Miner  Esaoli  cao  pOfnlaM  iIm  SEM  mnyil 
atilt  •  titnpk  qaabtitive  tciic  Ibr  indrvklBil  twgctt  tiefe 
luraiat  ihcir  Mcitfioa  lo  csslaitiit  objective*  piirwbc. 

-  ORCA  is  devilof bit  toii-MloauKd  SE.M  populition 
•echaicBM  band  oa  PTL  vilws,  targii  and  threii  data, 
aad  geofnpbic  coatideratlmit. 
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Figure  2  The  SEM  Concept 

We  discuss  the  SEM  in  conjunction  with  target  allocation  tools  because  it  provides 
quantitative  measures  of  target  value  and  modeling  of  the  relationships  between  targets 
that  mesh  with  common  sense  notions.  These  values  are  useful  in  the  objective  functions 
used  in  the  GRASP  procedure. 
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The  SEM  was  conceived  and  first  demonstrated  by  ORCA  during  the  DARPA  JFACC 
program,  as  part  of  ORCA’s  effort  to  develop  a  new  command  and  control  process  for 
dynamically  allocating  aircraft  to  objectives.  In  subsequent  IR&D,  the  SEM  was 
incorporated  as  a  key  component  of  ORCA’s  HEX  tool.  Extensive  experimentation  has 
validated  the  usefulness  of  the  SEM  as  a  means  of  modeling  objective  values  in  the 
allocation  process  and  encouraging  cooperative  behavior. 


The  JFACC  Component  of  LNAVSIM  has  a 
SEM  Tool,  shown  at  the  right,  for  assigning 
values  to  mission  tasks  and  synergetic  pairs 
of  tasks.  Through  research  and 
experimentation,  ORCA  has  determined  that 
a  simple  qualitative  ranking  system  for 
target  value  is  sufficient  for  translating  the 
decision  maker’s  intent  into  quantitative 
values  for  use  in  allocation  algorithms.  The 
qualitative  target  values  used  are  as  follows: 
minimal,  low,  medium,  high,  and  critical. 

These  qualitative  rankings  map  to  the 
quantitative  values  1,  10,  100,  1000,  and 
10000,  respectively,  in  ORCA’s  target 
allocation  algorithms. 

Figure  3  JFACC  SEM  Tool 

Populating  the  SEM  using  the  tools  provided  by  the  JFACC  Component  is  a  manual 
process.  ORCA  is  developing  automated  and  semi-automated  population  techniques 
based  on  PTE  values,  target  and  threat  data,  and  geographic  considerations.  The  operator 
will  have  the  opportunity  to  modify  and  change  individual  values  produced  by  the 
automated  tools. 

2.2  Route  Planning 

Route  planning  is  the  lowest  level  in  the  mission  planning  process.  The  LNAVGEN 
component  provides  route  planning  tools  to  generate  routes  for  individual  vehicles  or 
flocks  of  vehicles. 

2.2.1  Autorouting 

Mission  planning  and  autorouting  easily  break  into  two  categories — ^pre-mission  and 
inflight.  Autorouting  usually  refers  to  the  generation  of  the  flight  path  while  mission 
planning  incorporates  other  aspects  of  the  mission  including  target  area  planning,  sensor 
management,  and  communications  planning.  ORCA  tends  to  attach  the  broader  mission 
planning  definition  to  autorouting  because  the  flight  plan  constrains  what  the  aircraft  can 
accomplish  just  as  much  as  the  mission  objectives  can  influence  the  flight  plan. 

OPUS  autorouting  is  a  fast  and  effective  method  for  generating  terrain-aware,  goal¬ 
seeking,  survivable  route  plans  for  individual  vehicles.  The  input  for  the  autorouter  is  an 
ordered  set  of  mission  tasks  or  objectives,  vehicle  performance  parameters,  threat 
susceptibility  data,  and  terrain  data.  The  autorouter  attempts  to  generate  a  route  that 
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optimizes  some  notion  of  mission  effectiveness  and  not  just  survivability.  The  output  of 
the  autorouter  is  a  detailed  set  of  way  points  for  a  route  that  accomplishes  the  goals 
assigned  to  a  particular  sortie  while  being  aware  of  threats  and  terrain. 

The  autorouting  algorithms  of  ORCA  are  fast  enough  to  generate  new  routes  in  response 
to  changes  in  the  threat  environment  or  mission  objectives.  Using  an  A*  algorithm,  a 
feasible,  terrain-aware  route  is  developed  that  minimizes  a  non-linear  threat  costing 
function  that  models  the  enemy  Command,  Control,  Communications,  and  Intelligence 
(C3I). 

2.2.2  Deconfliction 

There  are  at  least  three  aspects  to  deconfliction.  The  first  aspect  is  pro-active:  routes  can 
be  planned  in  such  a  way  as  to  preclude  conflict.  Exclusion  zones,  minimum  risk  routes 
for  safe  ingress  and  egress,  and  kill  boxes  are  all  mechanisms  to  prevent  conflicts. 

A  second  aspect  is  conflict  identification.  Routes  are  compared  in  order  to  identify 
regions  where  one  or  more  aircraft  are  scheduled  to  arrive  at  too  close  to  the  same  time. 
This  is  typically  less  of  a  problem  if  the  aircraft  are  in  the  same  unit.  The  distance  at 
which  a  wingman  might  fly  would  be  worrisome  if  the  aircraft  wasn’t  part  of  the  lead 
aircraft’s  group. 

Finally,  deconfliction  means  eliminating  any  conflicts.  To  be  able  to  enforce 
deconfliction  without  broadcasting  the  details  of  each  aircraft’s  routes  requires  use  of 
airspace  management.  At  ORCA,  we  have  considered  broadcasting  route  details  as 
constraints.  Each  squadron  would  be  assigned  a  priority  that  would  let  them  know  who 
needed  to  replan  in  case  of  a  conflict.  Other  mechanisms  (i.e.,  routing  protocols)  would 
be  employed  to  reduce  the  chance  of  conflict  when  generating  new  route  plans. 

2.2.3  Swarm  Management 

Route  planning  for  large  groups  of  vehicles  can  be  a  challenge  for  traditional  route 
planners  that  generate  routes  for  individual  vehicles.  During  the  LNAVSIM  program, 
ORCA  has  researched  alternative  route  planning  methods  for  large  groups  to  address  the 
planning  needs  of  “flocks”  (“swarms”)  -  large  groups  consisting  of  tens  or  hundreds  of 
vehicles. 

There  has  been  a  considerable  amount  of  research  into  flocking  behaviors,  including 
Reynolds  seminal  work  on  “boids”^.  In  the  paper  “Flocking  of  Autonomous  Unmanned 
Air  Vehicles”^,  Crowther  and  Riviere  apply  the  rules  of  flocking  (cohesion,  alignment, 
separation,  and  migration)  as  defined  by  Reynolds  to  the  problem  of  managing  the  flight 
of  a  number  of  autonomous  unmanned  air  vehicles.  In  their  studies,  they  simulated  the 
flight  of  a  flock  of  10  vehicles.  It  should  be  noted  that  this  simulation  did  not  include  any 


^  “Flocks,  Herds,  and  Schools;  A  Distributed  Behavioral  Model”,  Computer  Graphics,  21(4),  July  1987, 
pp.25-34 

^  “Flocking  of  Autonomous  Unmanned  Air  Vehicles”,  Bill  Crowther,  Lecturer,  School  of  Engineering, 
University  of  Manchester,  w.j.crowther@man.ac.uk;  Xavier  Rivier,  Research  Student, 
xavier.riviere@caramail.com 
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threats  or  military  objectives.  The  focus  of  the  paper  was  to  demonstrate  flocking 
behaviors  and  investigate  the  relationship  between  various  flocking  rules  and  behaviors. 
Below  are  their  conclusions. 

•  “Flocking  offers  a  potentially  simple  and  efficient  way  of  managing  the  flight  paths 
of  a  large  number  of  small  autonomous  UAVs  such  that  the  risk  of  collision  and/or 
the  need  for  evasive  manoeuvers  is  reduced.” 

•  “The  way  in  which  flocking  rules  are  implemented  depends  strongly  on  the  nature  of 
the  flight  control  system  available  on  the  target  flight  vehicle.” 

•  “Basic  flocking  behaviour  can  be  obtained  as  the  result  of  application  of  just  two 
rules:  cohesion  and  alignment.  However  the  effects  of  rules  are  not  simply  additive.” 

•  “The  time  taken  to  achieve  coherent  flocking  behaviour  is  reduced  by  increasing  the 
cohesion  and  alignment  rule  strengths.  However  increasing  the  strengths  too  far  leads 
to  oscillatory  behaviour  and  increased  flock  convergence  time.” 

•  “Flock  behaviour  over  time  can  be  characterised  usefully  by  the  time  variation  of  two 
statistical  parameters:  the  mean  radius  between  flock  members  (flock  density)  and  the 
heading  angle  standard  deviation.” 

These  findings  are  similar  to  those  ORCA  documented  in  the  briefing  “Flocking 
Algorithms”,  in  June  2002. 

ORCA  developed  a  flocking  capability,  or  “swarm  management,”  for  LNAVSIM,  during 
Phase  11.  This  method  uses  a  modified  boids  approach  which  insures  that  the  physics  of 
flight  performance  is  maintained  and  creates  the  notion  of  a  “virtual  lead”  vehicle  around 
which  other  vehicles  flock.  Swarm  management  allows  the  user  to  group  vehicles  in 
swarms  and  generate  routes  for  the  swarms  as  opposed  to  generating  routes 
independently  for  each  vehicle.  Swarm  management  provides  an  alternative  to 
autorouting  in  an  environment  without  threats  and  could  be  used  to  generate  routes  for 
missions  such  as  surveillance  in  low  threat  areas. 

2.3  Dynamic  Tasking  and  Pianning 

These  two  functions  make  use  of  the  existing  capabilities  to  allocate  targets,  sequence  the 
mission  objectives,  and  generate  new  route  plans.  Time  critical  targets,  changes  in  the 
battlefield,  aircraft  that  take  more  than  half  a  day  to  reach  the  target  area,  and  uavs  that 
are  inherently  re-programmable  all  create  a  demand  for  dynamic  tasking  and  planning. 
The  ability  to  replan  quickly  in  face  of  changing  conditions  is  the  essence  of  having  a 
short  “observe,  orient,  decide,  acf ’,  or  OODA,  loop.  Col.  John  Boyd  showed  that  having 
a  shorter  OODA  loop  than  your  opponent  is  a  key  indicator  of  success  in  military 
operations."^  Automated  decision  aids  can  be  important  tools  in  developing  and  assessing 
plans  when  responding  dynamically  and  therefore  shortening  the  OODA  loop. 

There  are  several  levels  of  replanning  of  interest.  The  highest  level  involves  changing 
strategic  objectives  leading  to  a  change  in  objectives  and  their  priorities.  These  changes 
can  create  the  demand  for  a  new  allocation  of  objectives  to  force  elements — the  force 


“Boyd:  The  Fighter  Pilot  Who  Changed  the  Art  of  War”  Robert  Coram,  Little  Brown  &  Company,  2002 
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allocation  problem  at  the  JFACC  level.  In  current  day  planning,  the  JFACC’s  commands 
flow  to  wings  and  squadrons  who  would  then  have  a  smaller  allocation  problem.  Each 
squadron  or  uav  pod  would  also  have  to  allocate  targets  and  objectives  to  its  members. 
Although  the  mathematics  is  the  same,  we  have  been  referring  to  this  as  the  target 
allocation  problem. 

At  the  lowest  level  is  route  replanning  for  each  sortie.  If  there  is  a  change  in  objectives,  it 
is  obvious  that  the  route  should  change  as  well.  The  route  might  also  change  if  there  is  a 
change  in  the  threat  laydown. 

2.4  Analysis 

LNAVSIM  is  an  analysis  tool  to  evaluate  command,  control,  and  operations  concepts  and 
strategies  for  large  force  structures  involving  a  variety  of  aircraft  types.  OPUS  provides  a 
suite  of  analysis  tools  that  can  be  accessed  by  LNAVSIM  components  through  the  OPUS 
API.  Below  is  a  list  of  available  analysis  features. 

Sortie  Attrition 

The  probability  of  survival  for  a  sortie  route  is  computed  using  a  deterministic 
methodology.  Additional  route  figures  of  merit  are  available  including  the  number  of 
SAM  shots,  amount  of  exposure  to  EW/GCI  radars,  amount  of  exposure  to  tracking  radar, 
and  track  time  by  sites  and  networks. 

Interactive  Simulation 

A  discrete  event  simulation  models  the  execution  of  one  or  more  sorties  against  the  threat 
laydown.  SAM  and  AI  launches  are  determined  by  the  defense  network  using  one  of 
several  decision  criteria.  SAM  and  AI  engagement  outcomes  are  sampled  from 
probability  distributions  determined  by  vehicle  geometry. 

Monte  Carlo  Simulation 

Multiple  simulations  may  be  executed  to  collect  statistics  for  the  average  and  standard 
deviation  for  all  vehicle  figures  of  merit. 

Exposure  Reports 

Reports  on  exposure  of  sortie  routes  to  any  combination  of  threat  types  can  be  computed. 
Logistics 

Reports  on  fuel  use  are  available  by  strike  base,  vehicle  types,  and  time  on  target,  as  is 
information  on  takeoffs,  landings,  fuel  throughput,  and  aircraft  flying. 

3  LNAVSIM  Concepts  of  Operation 

3.1  LNAV  Analysis  Environment 

In  the  LNAVSIM  concept,  the  one- vehicle,  single-route  notion  is  replaced  with  vehicle 
control  paradigms  for  multiple  types  of  vehicles  in  user-specified  numbers,  route 
optimization  routines  for  multiple  vehicles,  and  vehicle  intradependent  proximity 
behavior  logic  necessary  to  simulate  coordinated  vehicle  movements  involving  multiple 
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vehicles.  In  addition,  simulated  visuals  from  virtual  terrain  sensors  onboard  an  unmanned 
vehicle  could  be  used  to  present  visual  cues  of  the  target  airspace. 

Imagine  having  the  flexibility  to  model  and  simulate  a  wing  of  fully  coordinated  and 
intradynamically  linked  ucavs  flying  in  formation  until  they  break-off  from  each  other  to 
pursue  individual  mission  objectives,  and  then  later  converge  as  they  complete  their 
mission  to  return  home.  System  users  of  LNAVSIM  will  be  able  to  model  and  simulate 
various  battlespace  conditions,  and  confront  them  with  open  and  flexible  user  defined 
LNAV  scenarios.  This  is  the  concept  of  operations  provided  by  the  LNAVSIM  analysis 
environment. 

3.2  UAV  Command  and  Control 

Command  and  control  is  entering  a  new  era.  There  are  several  forces  at  work  that  will 
soon  make  the  synchronous  24  -  72  hour  process  too  unwieldy.  One  of  those  forces  in  the 
employment  of  unmanned  aircraft  whose  control  is  inherently  asynchronous.  New  tools 
will  be  required  to  address  the  new  weapons  systems  being  developed. 

A  key  part  of  the  LNAVSIM  program  is  the  LNAVGEN  component,  which  provides 
software  tools  for  target  allocation,  route  planning,  swarm  management,  evaluation,  and 
analysis.  The  LNAVGEN  tool  is  an  example  of  the  type  of  mission  planning  tool  that  can 
address  the  mission  planning  needs  of  uavs  and  ucavs.  ORCA  technology,  accessed 
through  the  LNAVGEN,  can  provide  the  operator  with  automated  target  allocation,  route 
planning,  group  planning  for  a  pod  of  vehicles,  and  analysis  and  evaluation  tools.  These 
tools  present  the  operator  with  actionable  intelligence  -  information  that  is  presented  in  a 
form  that  enables  the  operator  to  do  something  constructive  -  and  the  decision  aids  help 
to  increase  the  operator’s  span  of  control.  The  SEM  is  a  key  ingredient  of  the  allocation 
process. 

3.2.1  Actionable  Intelligence 

A  current  important  phrase  for  designing  and  evaluating  C2  technology  is  “actionable 
intelligence.’’  What  it  means  is  that  information  that  is  presented  to  an  operator  should  be 
in  a  form  that  enables  the  operator  to  do  something  constructive.  In  general,  we  expect 
the  tools  we  are  designing  to  increase  user  situation  awareness  and  to  display  data  in  such 
a  way  that  it  shows  the  situation  and  highlights  potential  actions.  When  a  threat  pops  up 
or  a  new  target  presents  itself,  our  goal  is  to  quickly  be  able  to  present  the  operator  with 
at  least  one  choice  of  a  response  and  provide  quantitative  data  scoring  for  the  various 
response  options.  For  example,  if  a  threat  pops  up,  our  tools  can  provide  metrics,  such  as 
survivability  and  mission  effectiveness,  for  the  current  route  given  the  new  threat.  The 
operator  can  compare  these  metrics  with  the  original  route  metrics  and  determine  if 
replanning  is  necessary.  After  using  the  autorouter  to  replan  the  route,  the  operator  can 
view  the  metrics  for  the  new  route  and  compare  them  with  the  metrics  for  the  current 
route  plan  before  assigning  the  new  route  to  the  vehicle.  ORCA’s  automated  tools  can 
produce  the  metrics  and  plan  the  routes  quickly,  allowing  the  operator  sufficient  time  to 
analyze  the  options. 
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3.2.2  Span  of  Control 

The  number  of  aircraft  controlled  by  each  operator  is  the  span  of  control.  Automated 
planning  tools  increase  the  operator’s  span  of  control  by  shifting  much  of  the  mission 
plan  workload  to  the  computer,  thus  freeing  the  operator  to  concentrate  on  other  tasks, 
such  as  analyzing  SAR  images  and  other  intelligence  data.  Increasing  the  span  of  control 
while  maintaining  effectiveness  is  a  goal  of  several  unmanned  aircraft  programs. 
Currently,  some  unmanned  vehicles  require  more  than  one  operator  to  control  a  single 
vehicle.  One  operator  controls  the  aircraft  while  others  are  in  charge  of  managing  the 
sensors  and  analyzing  sensor  data.  We  envision  a  single  operator  controlling  multiple 
aircraft  using  LNAVGEN.  Increasing  the  capability  of  C2  decision  aids  and  automating 
tasks  such  as  target  allocation  and  route  planning  can  help  increase  the  span  of  control. 

3.2.3  Managing  the  SEM 

The  SEM  is  a  key  element  of  the  allocation  process  and  aids  in  coordinated  group 
planning  by  modeling  the  synergetic  effects  produced  by  pairs  of  missions.  It  enhances 
the  operator’s  ability  to  model  objective  values  and  enriches  the  allocation  process,  but 
requires  an  ongoing  effort  to  manage  and  update  the  values  for  objectives  and  synergetic 
effects.  ORCA  is  designing  automated  SEM  population  tools  that  will  help  lessen  the 
burden  on  the  operator.  ORCA  is  also  researching  methods  to  generalize  the  SEM 
concept  from  pairs  of  tasks  to  groups  of  tasks.  Such  a  generalization  will  offer  more 
flexibility  to  decision  makers  and  planners. 

3.3  Pod  Control  Concepts 

3.3.1  Pod  Control 

A  group  of  uav/ucav  needs  to  be  controlled.  When  given  an  appropriate  set  of  mission 
objectives  for  the  aircraft  and  the  threat  laydown,  LNAVGEN  tools  can  be  used  to 
automatically  allocate  aircraft  to  objectives,  generate  route  plans,  analyze  the  proposed 
routes,  and  dynamically  replan  missions  while  the  aircraft  are  in  flight  due  to  any  changes 
in  the  planning  problem.  An  LNAVGEN  client  application,  such  as  the  POPI,  allows  the 
operator  to  access  LNAVGEN  mission  planning  functionality  for  pod  control  and 
provides  visualization  of  mission  plans. 

3.3.2  Multiple  Operators 

The  LNAVSIM  architecture  allows  multiple  LNAVGEN  clients  to  operate 
simultaneously.  The  JFACC  has  the  responsibility  of  allotting  aircraft  and  mission  tasks 
to  each  operator.  Each  operator  then  develops  detailed  mission  plans  for  his  group  of 
vehicles. 

3.3.3  Dynamic  Planning 

The  LNAVSIM  researcher/analyst  will  have  the  capability  to  autonomously  reallocate 
mission  objectives  and  recalculate  an  optimal  flight  plan  based  on  pop-up  threats,  a 
mission  replan  or  an  operator  approved  command  redirect  and  provide  the  flexibility  to 
update  the  current  flight  plan  in  near  real-time. 
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4  LNAVSIM  Software 

During  Phase  II,  ORCA  developed  LNAVSIM  software  that  provides  the  Air  Force  with 
a  state-of-the-art  air  war  planning,  modeling  and  simulation  environment.  Using  a  spiral 
development  approach,  ORCA  designed  four  versions  of  the  LNAVSIM  software.  Each 
version  was  shared  with  AFRL  for  input  on  the  design  and  features.  The  ORCA-AFRL 
interactions  helped  shape  the  final  version  of  the  software.  The  final  design  of  Phase  II 
includes  features  and  components  that  were  not  part  of  the  original  Phase  II  proposal  but 
were  identified  during  Phase  II  R&D.  The  culmination  of  this  Phase  II  SBIR  effort  was 
the  release  of  the  LNAVSIM  Version  1.0  software. 

LNAVSIM  1.0  software  is  designed  to  offer  flexibility  to  the  user.  Although  LNAVSIM 
is  designed  as  a  distributed  computing  environment,  all  components  could  be  hosted  on 
one  machine.  Some  components,  such  as  the  LNAVGEN  mission  planning  component, 
can  be  used  as  stand-alone  tools.  LNAVSIM  is  a  flexible  plug-and-play  environment  that 
supports  component  swapping,  including  simulation  environments.  The  components  of 
LNAVSIM  can  be  hosted  on  PC  or  Linux  platforms. 

4.1  LNAVSIM  Architectural  Design 

The  diagram  below  gives  the  high-level  architecture  of  the  LNAVSIM  environment. 


Figure  4  LNAVSIM  Architecture 

LNAVSIM  consists  of  multiple  components,  which  are  discussed  in  detail  in  section  3.2. 
The  AnySim  component  is  the  hub  of  the  LNAVSIM  environment.  Its  main  function  is  to 
handle  mail  message  traffic  between  the  components.  The  Pod  Operator  Planning 
Interface  (POPI),  a  prototype  mission  planning  station  developed  by  ORCA,  and  the 
Operator  Vehicle  Interface  developed  by  AFRL  are  client  applications  that  access  the 
mission  planning  and  analysis  services  of  the  LNAVGEN  Server.  The  JFACC  component 
is  a  basic  planning  tool  for  the  commander.  It  provides  tools  for  setting  objective  and 
synergetic  values  and  assigning  aircraft  and  objectives  to  pod  operators.  The  BOSS 
component  is  used  to  set  up  and  manage  the  scenario  and  the  simulation  environment. 
LNAVSIM  1.0  has  interfaces  with  the  OPUS  3,  JIMM,  and  Supressor  simulations. 
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The  LNAVSIM  components  work  together  in  a  distributed  computing  environment.  The 
components  interact  using  the  Remote  Method  Invocation  (RMI)  and  the  Simple  Object 
Access  Protocol  (SOAP).  This  design  gives  LNAVSIM  the  ability  to  run  across  multiple 
machines  using  different  operating  systems.  The  main  languages  of  LNAVSIM  are  Java 
and  C++,  which  allows  LNAVSIM  components  to  be  hosted  on  PC  or  Linux  platforms. 
The  diagram  below  shows  the  types  of  messages  and  data  that  are  passed  between 
components. 


Figure  5  LNAVSIM  Component  Communications 


4.2  Components 

4.2.1  LNAVGEN 

The  Large  Number  of  Air  Vehicles  Generator  (LNAVGEN)  is  a  stand-alone  mission 
planning  component  that  provides  tools  for  an  operator  to  control  a  group  of  vehicles.  It 
consists  of  two  sub-components,  the  LNAVGEN  client  and  the  LNAVGEN  server.  These 
components  provide  services  for  allocating  aircraft  to  mission  tasks,  generating  route 
plans,  evaluating  and  analyzing  mission  plans,  as  well  as  visualization  tools  to  display  the 
threat  laydown  and  view  mission  plans  and  sortie  routes. 

The  LNAVSIM  architecture  supports  the  use  of  multiple  LNAVGEN  components.  Each 
LNAVGEN  could  serve  as  the  planning  station  for  a  wing  or  the  control  station  for  a  pod 
of  unmanned  vehicles. 

4.2.1.1  LNAVGEN  Client 

A  client  application  is  used  to  access  the  mission  planning  services  of  the  LNAVGEN 
Server.  ORCA  has  developed  a  client,  called  the  Pod  Operator  Planning  Interface  (POPI), 
which  is  a  prototype  pod  operator  mission  planning  station.  AFRL  is  developing  the 
Operator  Vehicle  Interface  (OVI),  which  can  also  serve  as  an  LNAVGEN  client.  Other 
clients  could  be  developed  to  use  the  services  of  the  LNAVGEN  Server. 
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4.2.1.2  Pod  Operator  Planning  Interface  (POPI) 

The  POPI  is  a  sample  client  for  the  LNAVGEN  Server.  It  represents  a  simple  way  in 
which  one  can  take  advantage  of  all  the  functionality  bundled  into  LNAVGEN.  The  POPI 
represents  one  view  of  managing  a  group  of  assets. 


Figure  6  Pod  Operator  Planning  Interface  (POPI) 

The  POPI  provides  a  variety  of  evaluation  and  analysis  figures  of  merit  to  the  operator, 
including  probability  of  survival,  number  of  shots  by  threat  type,  track  time  by  radar  type, 
exposures  to  radar,  and  radar  probability  of  detection.  When  a  new  event  is  received  from 
the  simulation,  FOMS  are  recalculated  for  the  original  route.  If  a  new  route  is  planned, 
FOMs  for  the  original  and  new  routes  are  displayed  before  the  new  route  is  accepted  or 
rejected. 


Figure  7  POPI  Planning  Dialog  with  Figures  of  Merit 

4.2.1.3  LNAVGEN  Server 

The  LNAVGEN  server  provides  planning  services  to  the  LNAVGEN  client  by  accessing 
OPUS  3  services  for  allocation,  autorouting,  evaluation,  analysis,  data  management,  and 
the  Swarm  Management  component.  The  allocation  service  produces  an  ordered  list  of 
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mission  tasks,  called  a  “tie-up,”  for  each  vehicle.  The  tie-ups  serve  as  an  input  to  the 
autorouter.  Once  routes  are  generated  by  the  autorouting  service,  the  client  can  call  the 
evaluation  and  analysis  services  for  route  metrics.  The  flocking  service,  which  is 
provided  by  the  Swarm  Management  component,  provides  an  alternative  method  for 
generating  routes  for  groups  of  vehicles. 

4.2.2  JFACC 

The  force  commander  uses  the  JFACC  component  to  make  high-level  allotments  of 
aircraft  and  mission  tasks  to  pod  operators,  who  then  develop  detailed  mission  plans 
using  the  LNAVGEN  component.  The  JFACC  component  is  also  used  to  set  values  for 
mission  tasks  and  synergetic  values  for  pairs  of  tasks. 

The  diagram  below  shows  the  JFACC  map  display,  dialogs  for  making  assignments  of 
assets  and  objectives,  and  the  SEM  tool,  which  is  used  to  set  task  values. 


Figure  8  JFACC  Component  GUI  and  SEM  Tool 

The  JFACC  component  was  an  idea  that  emerged  during  the  LNAVSIM  Phase  II 
development  process  and  was  not  part  of  the  original  design.  In  its  current  form,  the 
JFACC  component  is  limited  to  the  manual  allotment  of  aircraft  and  mission  tasks  to  pod 
operators  and  assignment  of  values  to  mission  tasks,  as  part  of  the  POPI  initialization 
process.  The  JFACC  component  could  be  outfitted  with  automated  planning  tools  for 
force  level  allocation.  In  an  IR&D  effort,  ORCA  is  investigating  automated  SEM 
population  methods,  which  could  be  used  by  the  JFACC  component. 

4.2.3  AnySim 

The  AnySim  component  is  the  hub  of  the  LNAVSIM  environment.  The  idea  for  AnySim 
was  conceived  in  an  ORCA-AFRL  brainstorming  session  early  in  the  LNAVSIM  Phase 
II  program  and  was  envisioned  to  serve  as  a  single,  stable,  well-defined  interface  to 
provide  plug-and-play  capability  to  any  ^zVwulation  (hence  the  name,  AnySim).  During 
Phase  II  design  and  development,  the  AnySim  evolved  into  a  component  through  which 
LNAVSIM  components  communicate. 

As  currently  implemented,  the  AnySim  is  used  to  set  permissions  for  components  to 
participate  in  the  LNAVSIM  environment,  register  components,  set  rules  for  mail 
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message  traffic  between  components,  assign  transformations,  control  when  the  simulation 
starts  and  stops  and  its  pace,  and  manage  the  mail  message  traffic  between  components. 

4.2.3.1  GUI 

The  AnySim  has  a  graphical  user  interface  (GUI)  through  which  its  functions  are 
controlled  and  some  component  activities  can  be  monitored.  The  GUI  has  a  window  that 
displays  information  about  the  interaction  between  components  and  another  that  shows 
the  registered  components. 


Figure  9  AnySim  GUI 


4.2.3.2  Interface 

The  components  of  LNAVSIM  communicate  via  mail  messages  and  the  AnySim  serves 
as  the  central  post  office  for  all  mail  message  traffic.  Each  machine  hosting  LNAVSIM 
components  will  have  an  AnySim  Interface,  which  serves  as  a  local  post  office  to  handle 
all  mail  for  the  components  on  that  machine.  The  AnySim  checks  periodically  with  each 
AnySim  Interface  for  mail  messages. 

4.2.3.3  Mail  Messages 

The  components  of  LNAVSIM  communicate  via  mail  messages  using  the  Simple  Object 
Access  Protocol  (SOAP)  mail  message  protocol.  SOAP  allows  applications  to 
communicate  using  hypertext  transfer  protocol  (HTTP),  which  is  supported  by  all 
Internet  browsers  and  servers.  SOAP  provides  a  platform-independent  and  language- 
independent  method  for  applications  to  communicate.  SOAP  messages  are  formatted 
using  the  extensible  Markup  Language  (XML).  XML  is  similar  to  HTML  in  that  it  uses 
tags  and  attributes,  but  XML  is  fundamentally  different  than  HTML:  HTML  is  used  to 
display  data  and  XML  is  used  to  describe  data. 

To  communicate  using  SOAP,  a  sender  must  package  a  message  as  a  SOAP  message  and 
the  receiver  must  have  a  way  to  identify  the  message  as  a  SOAP  message  and  direct  it  to 
the  appropriate  service.  Tomcat  and  Axis  are  the  enabling  technologies  for  these 
processes.  The  sender  uses  Axis  to  package  a  message  as  a  SOAP  message.  The  receiver 
side  has  multiple  services  for  processing  the  message:  the  Tomcat  web  server,  the  Axis 
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SOAP  server,  and  the  LNAVSIM  serviees  used  by  Axis  such  as  the  LNAVGEN  Server 
and  the  Scenario  Generator.  Tomcat,  unlike  some  other  web  servers,  has  the  ability  to 
recognize  an  XML  message,  which  is  necessary  when  using  SOAP.  Tomcat  parses  any 
XML  messages  it  receives.  If  the  message  is  a  SOAP  message.  Tomcat  will  find  a  tag 
that  will  cue  Tomcat  to  forward  the  message  to  Axis,  the  SOAP  server.  Axis  forwards  the 
request  to  the  appropriate  LNAVSIM  service. 


The  diagram  below  gives  details  of  the  mail  process. 

Component  A  :  AnvSim  Java  IF  :  AnvSimlF  :  AnvSimRemoteMailManlF  :  Axis  : 


Sends  Mail 


Tomcat :  AxisToolkit : 


!◄ - ^ - 

Tocat  receives  http 


^ - 

Axis  Toolkit  converts  to  SOAP  message  : 


Places  Mail  In  outbox 


^ - 

Calls  WebService  : 


[◄ - 

Axis  Processes  SOAP  : 


◄ - 

Receives  Mail  From  Outbox  : 


Figure  10  Mail  Message  Details 

4.2.4  BOSS 

The  Broad  Overseer  of  the  Scenario  and  Simulation  (BOSS)  component  is  used  to  help 
set  up  the  scenario  and  to  make  changes  to  the  state  of  entities  during  the  simulation.  The 
subcomponents  of  the  BOSS  are  the  Scenario  Generator  and  the  Simulation  Interface. 


Figure  11  BOSS  GUI 

The  BOSS  has  access  to  all  scenario  data  and  knows  all  LNAVSIM  players.  The  BOSS 
can  change  the  initial  threat  laydown  and  is  responsible  for  setting  transformations  for 
each  POPI.  During  the  simulation,  the  BOSS  is  able  to  add  or  delete  entities  (vehicles, 
targets,  etc.)  in  the  simulation. 
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4.2.4.1  Scenario  Generator 

The  Scenario  Generator  is  a  GUI-less  server  that  provides  initial  target  and  threat  location 
data  to  the  LNAVGEN  clients.  The  Scenario  Generator  imports  scenario  data  from  the 
simulation,  prepares  a  data  file  for  each  LNAVGEN  client  by  applying  the 
transformations  for  that  client  to  the  ground  truth  data  obtained  from  the  simulation,  and 
then  sends  data  to  the  clients. 

4.2.4.2  Simulation  Interface 

The  plug-and-play  nature  of  LNAVSIM  allows  any  simulation  to  be  used  by  LNAVSIM, 
provided  the  simulation  has  an  interface  with  the  AnySim  component.  The  Interface 
Design  Document  (IDD)  provides  the  simulation  interface  requirements.  The  final 
version  of  LNAVSIM  developed  in  Phase  II  of  this  SBIR  program  can  interface  with  the 
JIMM,  Suppressor,  and  OPUS  3  simulation  environments. 

The  simulation  interface  passes  sortie  routes  from  LNAVGEN  clients  to  the  simulation 
and  sends  back  updates  on  sorties  and  changes  in  targets  and  threats.  Update  messages 
from  the  simulation  are  filtered  and  transformed  according  to  transformation  rules  by  the 
simulation  interface  and  then  sent  to  individual  pod  operators. 

4.2.4.3  Transformations 

Transformations  are  a  device  to  filter  and  control  the  information  provided  to  each 
LNAVGEN  Client.  Just  as  in  a  real  combat  situation,  mission  plans  in  LNAVSIM  will  be 
affected  by  an  operator’s  perception  of  the  battlefield.  This  perception  is  based  on  the 
intelligence  information  available  to  the  operator  and  in  most  cases  will  differ  from 
ground  truth.  For  example,  the  aircraft  under  the  control  of  an  operator  may  not  be 
capable  of  detecting  threats  of  a  certain  type,  in  which  case  the  operator  would  not  know 
about  these  threats  unless  she  had  another  intelligence  source.  Transformations  are  used 
in  LNAVSIM  to  simulate  these  intelligence  gaps. 

Transformations  are  defined  for  each  LNAVGEN  Client  in  the  BOSS  component  and 
implemented  in  the  Scenario  Generator  and  Simulation  Interface. 

4.2.5  Simulation 

The  simulation  engine  is  the  driving  force  behind  the  dynamic  LNAVSIM  air  war 
environment.  Without  the  simulation,  the  components  of  LNAVSIM  are  reduced  to  static 
planning  and  computing  tools  that  solve  single  pre-mission  planning  problems.  The 
simulation  provides  dynamic  events  such  as  pop-up  threats,  time-critical  targets,  and 
changes  in  aircraft  status.  The  simulation  could  also  model  weapon  and  sensor 
effectiveness,  and  provide  data  about  target  damage  and  target/threat  detection.  The 
simulation  is  initialized  with  the  ground  truth.  It  executes  sortie  route  plans  as  they  are 
received  and  can  change  the  status  of  threats  and  targets.  It  also  provides  the  clock  for  the 
LNAVSIM  environment.  LNAVSIM  Version  I.O  has  interfaces  with  the  OPUS  3,  JIMM, 
and  Suppressor  simulation  environments. 
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4.2.6  Route  Export  to  VBMS 

The  Virtual  Battlespace  Management  System  (VBMS)  supports  visualization  of  large- 
scale  tactical  engagements.  VBMS  was  originally  developed  at  Wright  Laboratories, 
Wright-Patterson  Air  Force  Base.  It  was  modified  and  then  integrated  with  MIL- 
AASPEM  by  Charles  River  Analytics. 

Any  vehicle  routes  generated  by  the  LNAVGEN  server  are  written  out  in  VBMS  format, 
in  addition  to  the  OPUS  format  used  by  LNAVSIM  components.  The  VBMS  route  fdes 
can  then  be  opened  and  viewed  with  VBMS. 

4.3  LNAVSIM  and  OPUS 

LNAVSIM  components  use  OPUS  3  services  for  mission  planning,  evaluation,  analysis, 
simulation,  and  data  management.  These  services  can  be  accessed  directly  through  the 
OPUS  API  or  across  the  Internet  as  web  services. 

4.3.1  OPUS  API 

The  OPUS  API  is  a  set  of  software  libraries  and  interfaces  that  allows  other  programs  to 
access  the  non-graphical  mission  analysis,  vehicle  allocation  and  autorouting  functions  of 
the  interactive  version.  LxOPUS  API  is  a  version  of  OPUS  that  runs  on  the  Linux 
operation  system. 

4.3.2  OPUS  Services 

4.3.2.1  Autoroutinq 

The  autorouter  component  produces  threat-avoiding,  goal-seeking,  terrain-aware  routes 
for  aircraft  with  conventional  or  Low  Observable  (LO)  Radar  Cross  Section  (RCS) 
signatures.  It  contains  threat  analysis  techniques  that  result  in  route  generation  speeds  far 
faster  than  traditional  time  step  /  ray  trace  approaches. 

4.3.2.2  Target  Allocation 

The  target  allocation  component  assigns  vehicles  to  sets  of  target  objectives  to  achieve 
force  application  goals.  The  assignment  process  considers  vehicle  resources  such  as  fuel 
and  available  weapons  and  sensors,  assignment  costs  such  as  vehicle  value  and 
probability  of  arrival,  and  target  values. 

4.3.2.3  Evaluation 

The  evaluation  component  provides  information  about  how  a  route  interacts  with  the 
theater  battle  space. 

4.3.2.4  Analysis 

The  analysis  component  provides  a  variety  of  figures  of  merit  for  attrition  analysis  and 
mission  effectiveness.  A  documented  C^I  model  that  includes  hierarchical  defense 
command  modeling,  radar  detection,  and  SAM  engagement  and  AI  end-game  models  are 
implemented. 
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4.3.2.5  Data  Management 

The  data  component  provides  a  mechanism  for  managing  all  data  needed  by  the  other 
components. 

4.4  HLA  Compliance 

The  High  Level  Architecture  (HLA)  is  a  general-purpose  architecture  developed  under 
the  leadership  of  the  Defense  Modeling  and  Simulation  Office  (DMSO)  to  support  reuse 
and  interoperability  across  the  large  numbers  of  different  types  of  simulations  developed 
and  maintained  by  the  DoD.^  The  intent  of  this  architecture  is  to  encourage  the 
interoperation  of  simulations  and  the  reuse  of  simulation  components.  HLA  provides 
standardization  of  models,  templates,  and  interfaces  to  facilitate  simulation 
interoperability. 

LNAVSIM  Version  1.0  uses  a  simulation  to  drive  the  dynamic  environment.  In  the  sense 
of  HLA,  LNAVSIM  components  are  subcomponents  of  the  simulation  and  provide  data 
to  the  simulation.  LNAVSIM  does  not  directly  interoperate  with  multiple  simulations. 
The  simulation  being  used  by  LNAVSIM  may  interact  with  other  simulations.  In  that 
case,  the  HLA  issues  apply  to  the  interoperability  of  those  simulations. 

5  LNAVSIM  Studies 

ORCA  performed  three  studies  during  Phase  II  to  demonstrate  LNAVSIM  tools  and  to 
provide  blueprints  for  the  types  of  mission  planning  studies  that  can  be  conducted  using 
LNAVSIM.  An  important  part  of  any  study  is  setting  up  the  data  and  these  studies  give 
insights  into  the  type  of  data  required  by  LNAVSIM  components. 

Below  is  a  summary  of  each  of  the  studies.  It  should  be  noted  that  the  target,  threat, 
aircraft,  sensor,  and  weapon  data  used  in  the  studies  was  not  real  data,  and  therefore  not 
much  weight  should  be  put  on  the  specific  results.  If  the  same  study  is  performed  with 
real  data,  the  results  may  vary. 

5.1  Study  1 :  Sensor,  Jammer,  Shooter 

In  this  study,  we  used  LNAVSIM  tools  to  investigate  the  effects  of  jamming  of  threats  on 
aircraft  mission  effectiveness  and  survivability.  We  considered  how  jamming  can 
enhance  missions  and  looked  at  the  consequences  of  failing  to  execute  jamming  missions. 
If  plans  are  generated  assuming  threats  will  be  jammed  and  then  the  jamming  is  not 
performed,  aircraft  could  be  more  vulnerable  than  if  the  planning  were  performed  without 
the  assumption  of  jamming  being  present.  This  type  of  study  can  help  planners  decide 
how  best  to  incorporate  plans  for  jamming  into  the  overall  planning  process. 

The  results  indicated  that  if  routes  are  planned  and  evaluated,  exposures  to  threats  are 
identified,  and  those  threats  are  jammed,  then  the  quality  of  the  mission  is  improved. 
However,  if  missions  are  planned  with  the  assumption  that  jamming  will  be  performed 
and  it  is  not,  the  mission  quality  is  diminished. 


^  DMSO  website:  https://www.dinso.mil/public/transition/hla/ 
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5.2  Study  2:  Hunter-Killer 

The  Hunter-Killer  seenario  involved  searehing  for  a  target  and  releasing  a  weapon  against 
it  once  its  location  has  been  determined.  In  the  Hunter-Killer  study,  a  target  was  located 
(imaged)  and  then  a  weapon  was  released  against  it.  We  investigated  the  influence  of  the 
aircraft’s  weapon  and  sensor  configurations  on  route  quality.  We  also  compared  the 
results  of  using  one  aircraft  versus  two  aircraft  to  perform  the  mission.  The  results  of  the 
study  indicated  that  the  choice  of  weapon  type  influences  mission  quality. 

5.3  Study  3:  UCAV  Command  and  Control 

The  LNAVSIM  report  “Command  and  Control  Issues  in  UAV  Operations”  discussed  a 
number  of  topics  related  to  unmanned  air  vehicle  operations.  One  important  issue  raised 
in  the  report  was  “span  of  control”:  the  number  of  unmanned  aircraft  controlled  by  an 
operator.  Automating  mission  planning  tasks  helps  to  increase  the  span  of  control  by 
freeing  the  operator  from  some  planning  duties.  It  is  important  to  investigate  which  tasks 
can  be  automated  and  which  tasks  should  be  left  to  the  human  operator. 

ORCA  has  developed  decision  aids  and  automated  tools  to  assist  an  operator  controlling 
a  group  of  aircraft.  In  this  study  we  focused  on  the  allocation  service  as  a  decision  aid. 
ORCA’s  HEX  target  allocation  tool  can  be  used  to  generate  assignments  of  aircraft  to 
mission  objectives,  such  as  sensor  imagining  assignments  and  weapon  release  tasks. 
ORCA’s  SEM  is  a  key  ingredient  of  HEX  and  a  useful  decision  aid  for  the  operator.  The 
SEM  enhances  the  ability  of  the  operator  ability  to  model  mission  objective  values  and 
enriches  the  allocation  process. 

LNAVSIM  components  make  use  of  the  HEX  tool  and  the  SEM.  The  POPI  is  used  to 
generate  mission  assignments  and  route  plans  for  a  group  of  aircraft.  Values  for  the  SEM 
can  be  set  using  the  JFACC  component.  These  values  are  sent  by  the  JFACC  to  the  POPI, 
which  passes  them  along  to  the  LNAVGEN  server  when  the  allocation  service  is  called. 
The  LNAVGEN  server  accesses  the  HEX  tool  through  the  OPUS  API  to  generate  the 
allocation  for  the  POPI. 

In  this  study,  we  used  LNAVSIM  to  compare  the  results  of  allocating  with  and  without 
using  automated  target  allocation.  To  investigate  the  impact  of  the  SEM,  we  compared 
results  for  various  parameter  settings.  The  study  indicated  that  the  SEM  and  automated 
allocation  tools  used  in  LNAVSIM  would  produce  coordinated  and  cooperative 
assignments  without  degrading  mission  quality. 

6  LNAVSIM:  The  Future 

During  Phase  II,  ORCA  has  designed  and  developed  a  number  of  components  and  tools 
that  comprise  the  LNAVSIM  air  war  modeling,  planning  and  simulation  environment. 
However,  LNAVSIM  is  a  work  in  progress  and  ORCA’s  vision  of  LNAVSIM, 
summarized  in  this  document  and  presented  in  more  detail  in  “Operational  Concepts”, 
extends  beyond  the  current  implementation.  In  this  section,  we  give  some  possibilities  for 
LNAVSIM  enhancements.  As  we  have  done  throughout  Phase  I  and  Phase  II,  we  present 
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these  ideas  as  a  way  of  stimulating  discussions  with  AFRL  about  the  possibilities  for 
development  in  a  Phase  III  effort. 

6.1  Architecture  and  Design  Assessment 

The  LNAVSIM  Version  1.0  software  represents  one  implementation  of  the  LNAVSIM 
vision.  The  first  step  in  designing  an  enhanced  LNAVSIM  environment  will  be  to  assess 
the  strengths  and  weaknesses  of  the  current  architecture  and  individual  components.  This 
assessment  has  already  begun  at  ORCA. 

One  important  aspect  of  the  design  that  is  not  apparent  to  LNAVSIM  users  is  the 
middleware  that  allows  communications  between  distributed  components.  ORCA  has 
learned  about  middleware  possibilities  through  this  R&D  effort.  We  have  ideas  about 
how  to  improve  on  the  current  implementation.  A  goal  for  next  version  of  LNAVSIM 
will  be  to  simplify  the  middleware  and  mail  message  handling.  Possibilities  include 
eliminating  the  use  of  RMI  and  using  the  Direct  Internet  Message  Encapsulation  (DIME) 
format  to  improve  interoperability  between  Java  and  .NET. 

6.2  Enhanced  Tools 

Experience  from  the  LNAVSIM  software  development  process  and  in-house  OPUS  3 
R&D  have  given  us  ideas  for  enhancements  to  current  LNAVSIM  tools  and  components. 

6.2.1  Improved  Set  of  FOMS 

For  OPUS  3,  ORCA  is  considering  several  new  analysis  features,  including  an  expanded 
set  of  FOMs,  which  will  provide  planners  with  more  decision  aids.  In  particular,  ORCA 
is  investigating  force-level  mission  effectiveness  metrics  and  allocation  metrics,  and 
temporal  based  metrics.  New  OPUS  3  metrics  and  analysis  tools  will  be  available  for  use 
in  LNAVSIM  components  through  the  OPUS  API  or  as  a  web  service. 

6.2.2  Flocking 

The  current  flocking  capability  allows  routes  to  be  generated  for  groups  of  vehicles  and  is 
similar  to  the  “holds”  implementation  of  Reynolds.  However,  ORCA’s  flocking 
algorithm  uses  the  notion  of  a  virtual  lead  route  -  a  route  that  the  group  tries  to  follow 
while  obeying  other  flocking  rules.  The  flocking  algorithm  generates  the  virtual  lead’s 
route.  A  possible  change  would  be  to  design  a  graphical  tool  that  would  allow  the 
operator  to  draw  the  virtual  lead’s  route  on  the  map  display. 

Another  area  to  investigate  is  the  concept  of  operations  for  groups  of  vehicles  on  the 
order  of  one  hundred,  or  even  one  thousand,  vehicles.  The  role  of  flocking  will  become 
more  important  if  the  notion  of  “large  numbers”  is  increased  one  or  two  orders  of 
magnitude. 

6.2.3  Deconfliction  Tools 

Through  OPUS  R&D,  ORCA  has  developed  a  prototype  time-line  viewer  that  provides  a 
tool  to  identify  and  resolve  route  conflicts  for  a  group  of  vehicles.  The  tool  flags  routes 
that  fall  within  a  safe  buffer  around  other  vehicles’  routes  and  allows  the  user  to  change 
the  start  and/or  end  times  of  routes  to  remove  these  conflicts.  An  operator  could  use  this 
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automated  planning  aid  during  the  route  planning  process  for  a  pod  of  vehicles.  It  could 
also  be  used  by  the  JFACC  when  evaluating  force-level  plans 

6.2.4  Automated  Tools  for  the  JFACC 

In  the  current  implementation,  the  tools  for  the  JFACC  are  all  manual.  ORCA  is 
investigating  automated  methods  for  populating  the  SEM.  ORCA  is  also  researching 
alternative  allocation  methods,  including  automated  tools  for  force-level  allocation  that 
are  less  detailed  than  those  currently  employed  in  the  LNAVGEN  component.  With  such 
a  tool,  the  JFACC  could  make  high-level  allocations,  and  leave  the  detailed  planning  to 
the  pod  operator. 

As  mentioned  above,  the  time-line  viewer  may  be  another  automated  tool  that  could  be 
used  by  the  JFACC. 

6.3  New  Features 

In  our  on-going  research  effort,  we  recently  come  across  research  that  has  given  us  ideas 
for  new  features  for  LNAVSIM.  Below  we  discuss  two  possibilities:  vehicle 
communications  models  and  the  use  of  multiple  simulations. 

6.3.1  Vehicle  Communications  Models 

In  the  paper  “Minuteman:  Forward  Projection  of  Unmanned  Agents  Using  the  Airborne 
Internet”^,  written  in  support  of  the  ONR’s  MINUTEMAN  (Multimedia  Intelligent 
Network  of  Unattended  Mobile  Agents)  project,  the  authors  frame  the  importance  of 
autonomous  agents  such  as  unmanned  ground  and  air  vehicles  (“agents”)  in  the  future 
battlefield.  Agents  will  be  grouped  into  clusters  and  efficient  communication  between 
agents  (including  agents  from  different  clusters)  will  be  critical  to  the  success  of 
missions.  Missions  need  to  be  carefully  scheduled,  coordinated,  equipped  with  adequate 
resources,  and  monitored.  LNAVSIM  provides  a  platform  to  accomplish  many  of  these 
goals  (e.g.  monitoring  or  scheduling).  The  goal  of  the  MINUTEMAN  project  is  to  work 
on  the  concept  of  an  agile  and  dynamic  “Internet  in  the  Sky”  that  can  support  the 
demanding  communication  requirements  of  unmanned  missions. 

The  description  of  the  MINUTEMAN  project  lists  some  of  the  communication 
challenges  that  unmanned  missions  encounter,  such  as  agent  mobility,  quality  of  service, 
and  environment  changes  including  losing  key  assets.  LNAVSIM  uses  transformations  to 
model  the  “Quality  of  Service”  that  a  monitoring  agent,  like  the  POPI  or  OVI,  receives. 
The  paper  makes  a  clear  argument  that  communication  amongst  a  large  number  of  air 
vehicles  is  a  vital  function  and  an  important  topic  for  research.  There  are  many  possible 
schemes  to  handle  communication  between  air  vehicles  and  controllers.  A  “plug  and 
play”  communication  model  would  enhance  the  utility  of  LNAVSIM  for  communication 
studies  in  a  simulated  environment. 


“Minuteman;  Forward  Projection  of  Unmanned  Agents  Using  the  Airborne  Intemef’,  Mario  Gerla, 
Kaixin  Xu,  Computer  Science  Department,  University  of  California  Los  Angeles;  Allen  Moshfegh,  Office 
of  Naval  Research 
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6.3.2  Incorporate  Other  Simulations 

Incorporating  a  wider  range  of  models  and  simulations  would  enhance  LNAVSIM 
analysis  and  simulation  possibilities.  In  the  paper  “A  Case  Study  on  Model  Integration, 
Using  Suppressor”’,  Gregory  Douglas  presents  techniques  to  allow  the  integration  of 
multiple  models  and  simulations.  An  environment  that  supports  the  integration  of 
external  models  and  simulations  should  help  increase  the  use  of  modeling  and  simulation 
technologies,  a  desire  of  the  Department  of  Defense  (DoD).  Suppressor  already  provides 
rich  analysis  capabilities  so  it  was  chosen  as  the  “glue”  simulation  that  would  hold 
everything  together.  It  was  modified  to  allow  any  piece  of  data  to  originate  from  an 
external  simulation.  This  was  accomplished  by  modifying  the  interface  architecture  to 
Suppressor  so  that  a  simulation  that  implemented  the  interface  could  be  “plugged  in”. 
The  user  would  be  able  to  choose  what  model(s)  or  simulation(s)  would  control  an 
entity’s  movement,  the  Command  and  Control  system,  sensors,  and  weapons. 

The  ability  to  integrate  simulations  and  models  should  result  in  an  increased  use  of 
simulations.  LNAVSIM  similarly  allows  an  ability  to  use  different  simulations,  with 
different  model  fidelities.  By  facilitating  the  ability  of  other  simulations  to  “plug-in”  to 
LNAVSIM,  richer  analysis  will  be  possible  because  results  from  multiple  models  can  be 
used  to  enhance  algorithms. 

7  Conclusion 

This  is  the  final  report  of  the  ORCA  LNAVSIM  SBIR  Phase  II  effort.  During  Phase  II, 
ORCA  continued  the  research  effort  begun  in  Phase  I  and  implemented  a  prototype 
LNAVSIM  environment:  LNAVSIM  Version  1.0.  During  our  research  effort  and 
development  of  LNAVSIM  Vl.O,  we  have  gained  valuable  insight  into  the  LNAV 
modeling,  mission  planning,  and  simulation  problem  and  the  challenges  of  developing  a 
flexible  distributed,  open  architecture  in  which  software  tools  interact  to  form  a  dynamic 
LNAV  simulation  environment. 

The  LNAVSIM  software  designed  during  this  effort  represents  state-of-the-art 
technology  for  mission  planning,  modeling,  and  simulation.  ORCA  is  prepared  to 
leverage  the  knowledge  and  experience  gained  through  this  program  and  our  on-going  in- 
house  R&D  efforts  to  enhance  the  LNAVSIM  architecture,  algorithms,  and  tools  in  a 
Phase  III  effort. 


’  “A  Case  Study  on  Model  Integration,  Using  Suppressor”,  Gregory  Douglas,  L-3  Communications 
Corporation,  Link  Simulation  and  Training  Division 
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